Methods and apparatus for complementing user entries associated with events of interest through context

ABSTRACT

Data validation techniques are provided. For example, such techniques complement user entries associated with events of interest through context. In one aspect of the invention, a technique for processing one or more user entries associated with one or more events of interest includes the following steps/operations. Context associated with the one or more events of interest is obtained. At least a portion of the obtained context is associated with one or more user entries representing events of interest. At least a portion of the one or more user entries is evaluated, responsive to at least a portion of the context. An indication of the one or more events of interest is provided, responsive to the evaluation.

FIELD OF THE INVENTION

The present invention relates to data validation through evaluatedcontext and, more particularly, to methods and apparatus forcomplementing user entries associated with events of interest throughcontext.

BACKGROUND OF THE INVENTION

Many applications, including applications associated with billing andexpenses, rely on user entry for detail. However, users are not alwayscomplete and accurate in the entries that they make. In an attempt toremedy this, pervasive computing applications abound that allowpoint-of-event entry for these applications so that required entries arefresh in the user's mind, and entered data is more accurate andcomplete. This does not prevent lost entries, such as charges which arelost as people forget to report on lab tests or encounters with medicalstaff.

Examples of such applications include personal digital assistant (PDA)based expense accounts and products such as “Patient Keeper ChargeCapture” available from Patient Keeper, Inc. of Brighton, Mass.

In specific applications, the time of reporting a specific occurrencecan impact the cost and payments exchange between businesses. There aretwo types of existing billing systems:

(1) Real-time billing systems - These are billing systems where thepayment is performed immediately at the time when the service isperformed or goods are being purchased. Examples of a few types ofreal-time payment systems include: pre-paid phone cards; cash payments(e.g., to supermarkets, to physicians, for work, etc.); electronicwallet (e.g., smart cards) where money transactions are being exchanged;and parking tickets where exit point payment is required.

(2) Periodic billing systems—These are billing systems where the paymentis being processed periodically at a later point in time to the time theservice or goods were provided. Most billing systems work in this mode.In those cases, the transaction is fed into the system either manuallyor semi-manually. Examples of a few types of such payment systemsinclude: regular phone bills, utility bills, healthcare insurance bills,expense accounts, police tickets, and ordering goods via phone orfacsimile.

In all the above cases, the quality of the data entered manually dependson human ability to listen and see accurate information, as well as totype accurately. It is clear that errors can always occur as a result ofhuman mistakes. Moreover, even in cases where systems can perform datacleansing and overcome some mistakes, timing can have an additionalimpact. Another example where timing can have significant impact onbilling is related to hospitalization. Insurance companies have specialcontrollers in hospitals that validate the time and reasons forhospitalization. Often today, the controllers must go back to theiroffices to report on hospitalization of their insured customers, andthus information is usually delayed by 24 hours. The temporalcharacteristic of the reporting event is critical to the costcalculation.

Filling in forms on the World Wide Web (e.g., using a personal computer)can be advantageous since logic programs can verify and check whetherthe form is filled in a reasonable manner. However, Web access is notalways available, nor is simple verification sufficient for identifyingall errors (especially errors of omission). Techniques in filling outelectronic forms are well known and disclosed, for example, in U.S. Pat.No. 5,704,029 issued Dec. 30, 1997 to G. V. Wright, Jr., and entitled“System and Method for Completing an Electronic Form.”

Techniques to enhance form completion are also known in the art. Forexample, “cookies” are used to allow forms to be filled in on the Webwith minimal additional data entry. Use of such cookies allows varioustechniques, such as prefix matching and attribute value pairs, in orderto determine what data goes into what field.

Form filling can also be enhanced with location-based knowledge. Forexample, the U.S. patent application identified by U.S. Ser. No.09/583,318 (Attorney Docket No. BOC920000023US1), filed on May 20, 2000,and entitled “Method and System for Increasing Ease-of-Use and BandwidthUtilization in Wireless Devices,” discloses using location to helpdetermine entries a user may be trying to make on a wireless device(e.g., filling in a uniform resource locator (URL) with car priceresearch sites when the user is standing in a used car lot).

Thus, in summary, data entry is often erroneous and subject to humanerror (e.g., incorrect information entry, partially incorrectinformation entry, failure to make an information entry). Whether paperor electronic, user error is responsible for many incorrect datarecords. What is needed is a technique for supplementing user entry witha validation data stream.

SUMMARY OF THE INVENTION

The present invention provides data validation techniques. For example,such techniques complement user entries associated with events ofinterest through context.

In one aspect of the invention, a technique for processing one or moreuser entries associated with one or more events of interest includes thefollowing steps/operations. Context associated with the one or moreevents of interest is obtained. At least a portion of the obtainedcontext is associated with one or more user entries representing eventsof interest. At least a portion of the one or more user entries isevaluated, responsive to at least a portion of the context. Anindication of the one or more events of interest is provided, responsiveto the evaluation.

The technique may further include obtaining a specification of contextassociated with one or more events of interest. Further, the techniquemay include specifying the one or more events of interest. Contextspecified may include a location, a time at location, a proximity to alocation, a proximity to a person, a proximity to a device, a proximityto a person satisfying a condition, a proximity to a location during aspecified time interval, an application invocation, a duration of anapplication invocation, a duration of an application focus on aparticular subject, an application invocation during a specified timeinterval, a user input, a duration of a user input session, a proximityto multiple persons and a location, a calendar, a work assignment,and/or a workflow stage. A location may include a physical location.Further, the technique may include mapping a physical location onto alogical location. Still further, a proximity may be determined inaccordance with an identification device.

Context may be obtained through a computer program, a file transfer, abatch mode, a communications network, a communications-enabled device,and/or a polling mechanism. Context may be obtained from one or moresources. Further, context may be obtained from a calendar, a globalpositioning system, user entry, a video, a sensor associated with aperson, a sensor not associated with a person, and/or a proximity to awireless access point.

The step/operation of associating context may be responsive to a time ofday, a time of event of interest, a location of event of interest, alocation of entity, a source of context, and/or an entity associatedwith context. The step/operation of evaluating the one or more userentries responsive to context may include a determination of validity, adetermination of a likelihood of validity, a determination of a missingentry, and/or a determination of a missing element of an entry. Adefined workflow of correlated events may exist and the associatedcontext may use a position in the workflow for determination. Thestep/operation of providing an indication may include a log, an errormessage, a warning, a default entry, an amended entry, a new entry, adeleted entry, a workflow, an e-mail, and/or a notification. Evaluationmay include the step/operation of, responsive to at least two sources ofcontext, creating a composed source of context. The composed source maybe created through a calculation.

In another aspect of the invention, a technique for validating one ormore expenses based on context data includes the followingsteps/operations. Context data is obtained in the form of a locationhistory for at least one user. Responsive to user entry of one or moreexpenses incurred, a location associated with an expense is determined.The user location history is reconciled with the location associatedwith the expense. An indication of the reconciliation is provided. Thetechnique may also include obtaining location history for at least onedevice.

In a further aspect of the invention, a technique for validating acharge based on context data includes the following steps/operations.Context data is obtained in the form of a charge history for at leastone client. One or more current charges for the client are compared toone or more previous charges for the client. The technique may alsoinclude comparing the one or more current charges for the client toprevious, similar charges for other clients.

In yet another aspect of the invention, a technique for validating acharge based on context data includes the following steps/operations.Context data is obtained in the form of a charge history for at leastone employee. A current charge for a client of the employee is comparedto one or more previous charges originating from the employee for theclient. The current charge for the client of the employee is compared tothe previous charges originating from the employee for all clients.

These and other objects, features and advantages of the presentinvention will become apparent from the following detailed descriptionof illustrative embodiments thereof, which is to be read in connectionwith the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an existing user data entrysystem;

FIG. 2 is a block diagram illustrating a user data entry system,according to an embodiment of the present invention;

FIG. 3 is a flow diagram illustrating a user data entry validationmethodology, according to an embodiment of the present invention; and

FIG. 4 is a block diagram illustrating a computer system suitable forimplementing a user data entry system, according to an embodiment of thepresent invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

It is to be understood that while the present invention will bedescribed below in the context of a medical services billingenvironment, the invention is not so limited. Rather, the invention ismore generally applicable to any environment in which it would bedesirable to provide techniques for validating user data entries basedon context. As used herein, the term “context” is generally understoodto refer to information about the physical or virtual environment of theuser and/or the computational device being used by the user.

In accordance with principles of the invention, it is realized that withcontext middleware, and sources of context such as location, it ispossible to complement user entries with context-based knowledge inorder to improve the quality of those entries. Principles of the presentinvention use context middleware to enable easy recording of contextstreams, and later reconciliation of, and validation with, user entries.This may result in an indication of support of the user entry, mayindicate possible errors in user entries, or may point out the absenceof a user entry where one may be desirable.

In the case of a hospital clinical care scenario, often charges forphysician visits are not levied on the patient, or may be leviedmistakenly without the physician visiting the patient. Charges formedication, x-rays and so on may contain similar errors.

In accordance with principles of the invention, events of interest aredefined as associated with context (e.g., location), or a composition ofcontexts (e.g., physician proximity to a patient in a patient room,medication cart proximity to a patient). The context collected may alsoinclude time on task (the amount of time spent in a patient room or theamount of time spent writing up notes about the visit). The contextassociated with these events of interest is received and logged, and islater reconciled with billing entries. These billing entries may be madeby the physician, by the nurse, by the administrator, etc.

The reconciliation may suggest that an entry is invalid, may suggestthat entries are contradictory, or may suggest that entries are missing.Responses to these suggestions may be dependent upon the application,policy, or both. However, some general examples of responses may includeprompting of a user to re-enter (or enter for the first time) data,automatically correcting the faulty (or missing) entry based on somepre-established policy, alerting someone other than the user that datais faulty or missing.

The business value is clear; hospitals (or, more generally, billingentities) may achieve more accurate billing. Expense accounts in anenterprise may be reconciled with location (with appropriate privacyguarantees of course). Other applications may include validation ofservice billings (e.g., repairmen or lawyers), validation of charge cardpurchases, and indication of identity theft, to name a few. That is, itis realized that today charge card companies and telephone companieslook for unusual patterns to determine theft likelihood (e.g., suddencharges in South America), but they cannot discover if reasonablecharges are wrong (e.g., a credit card charge for the purchase of gas inNew Jersey for a Westchester resident). However, in accordance with theteachings of the present invention, using context as a complementarytool can allow this to occur.

Note that incomplete context coverage (e.g., not able to get locationinformation at all places) may still result in value, as long as contextcoverage appropriate to the events of interest is available. Forexample, radio frequency identifier (RFID) tags may be used to identifypatients, and readers may be located at the entrance to magneticresonance imaging (MRI) rooms, x-rays, etc. This provides someassistance in reconciliation of data, and return value with minimumcapital expenditure. Further, adoption of RFIDs attached to mobiledevices like mobile MRI or attached to drug containers providesadditional business value such as the ability to locate and trace“stolen” entities. This has impact on the cost and expenses ofhealthcare organizations, retail store, container of goods, etc. In somecases, it can shift company balance sheets from debit to credit. Inaddition, by tracking the movement of those entities, it may be possibleto identify their destination. Smartcards are already vastly in use insome locations within the healthcare industry; patients identifythemselves to physicians, labs, radiology centers using their smartcards. The information provided is used to complement the context in aclinical event accurately and prevent errors in patient identificationand patient demographic information.

Extending the clinical events with context streams can be performedincrementally. In the example of the RFID based location awarenessabove, a facility may gradually install more RFID readers, and gainincremental value as the ability to identify location and proximityincreases. Another feature of the invention is the ability to usedifferent context sources. For example, location may be determined usingRFID as above for patients and by wireless proximity to a Bluetooth nodefor physicians carrying Bluetooth enabled devices (see, e.g., U.S. Ser.No. 09/784,975 (Attorney Docket No. YOR920010040US1), filed on Feb. 16,2001, and entitled “Systems and Methods wherein a Base DeviceFacilitates a Determination of a Location Associated with an Occurrenceof an Event”).

Another feature of the invention relates to the use of logicallocations. As an example, hospital location information can be mappedfrom specific coordinates onto logical locations, such as room numbersor room functions. For example, “operating room” may be mapped tomultiple coordinates representing multiple rooms. This allows entriescontaining the logical location to be more meaningful to users of thesystem, both in the specification of an event of interest and in laterdata entry or validation by individual users.

Another key feature of the invention is the ability to associate eventsin different points of the process that may be in different locationsgenerated by different users or systems, so that it is possible tocorrelate them later on and identify missing information. For example,when an order is being placed for a lab test, an event is beinggenerated and can be correlated with the event generated when the labresults are issued.

Referring initially to FIG. 1, a block diagram illustrates an existinguser data entry system that employs explicit data validation. As shown,user entry system 100 receives explicit input from, for example, usersor business processes through a variety of devices such as mobilecomputers 105, desktop computers 110, personal digital assistant orcellular phone devices 115 and backend systems 120. This explicit inputis stored in a data store 130, which could be a database, flat file, orother data storage subsystem.

Once available, the explicit input stored in 130 can be processed by areconciliation engine 150 according to one or more business rules storedin data store 140, such as meal and hotel limits or requirements to usethe lowest price airfare. It is to be appreciated that the businessrules may be entered and/or created via computer system 145, whileresults of the reconciliation engine 150 may be provided to computersystem 160.

The reconciliation engine 150 may verify that users have met thebusiness rules. If so, the system may approve the explicit data.Otherwise, the system may take any of a number of actions with theexplicit data together with the business rule that the explicit dataviolates. These actions include presenting the relevant data to the userwho entered the explicit data for further verification or to a differentuser (e.g., a manager or auditor) for independent verification.

The system depicted in FIG. 1 suffers from a number of problems. Onesuch problem is that the system can require unnecessary verification.Another is that the system cannot detect complex violations that couldbe detected with the addition of context information. In accordance withFIG. 2, an embodiment of a user data entry system according to theinvention, which addresses these and other problems, is described.

Referring now to FIG. 2, a block diagram illustrates a user data entrysystem, according to an embodiment of the present invention. User dataentry system 200 uses explicit entry provided by, for example, users orbusiness processes through a variety of devices such as mobile computers205, desktop computers 210, personal digital assistant or cellular phonedevices 215 and backend systems 220. In addition, the explicit dataprovided by these sources is stored in an explicit entry data store 230.Further, business logic specifications (i.e., business rules) are storedin data store 240. The data store 240 could be a database system, a flatfile, or any of a variety of other data stores. Computer system 245 maybe used to enter and/or create business rules.

System 200 also has a reconciliation engine 250. Once anomalies areidentified, they are presented to a user in one or more forms, such asan error message or a query or a request for confirmation. Such resultsmay be provided to computer system 260. The reconciliation engine 250uses the explicit data stored in the explicit entry data store 230together with the business logic specifications stored in the businessrules store 240. However, unlike reconciliation engine 150 (FIG. 1),reconciliation engine 250 also uses context information, stored in acontext log 275, and patterns based on that context, stored in apatterns database 290.

The context information is obtained via a variety of sources, such as271, 272, 273, 276, and 277. These sources may be connected sources(denoted with solid lines), such as 272, 273, and 276, or occasionallyconnected sources (denoted with dashed lines), such as 271 and 277, thatcollect context during periods of disconnection and report thatcollected context once connectivity has been reestablished. For example,a PDA in a hospital may collect data entered by a physician or collectedfrom the environment (e.g., an RFID reader). The PDA would operatedisconnected from the network while in the hospital, but would reconnectto the network once the physician reached an environment where wirelesscommunications are safe or where the device may be physically connectedvia a desktop or a wired network connection. Context may arrive to thesystem via a context service 270 and be forwarded to a data store (e.g.,the context log 275). Alternatively, context may arrive to the systemdirectly via the context log 275. Regardless of how context arrives,reconciliation engine 250 uses this context in a user data entryvalidation methodology illustrated in accordance with FIG. 3 anddescribed below.

Further, patterns of context data are observed in the context log 275 bya pattern miner 280. Once observed, the pattern miner 280 stores thepattern in a pattern database 290 for use by reconciliation engine 250.Data and pattern mining tools are well known in the art, and used toshield users from unwieldy bodies of data by analyzing the data,summarizing it, or drawing conclusions from the data that the user canunderstand. For example, one known computer software data mining productis IBM Corporation's “Intelligent Miner” which is operable in severalcomputing environments including AIX, AS/400, OS/390, Windows NT, andWindows 2000, and Solaris. The IBM Intelligent Miner is an enterprisedata mining tool, designed for client/server configurations andoptimized to mine very large data sets, such as gigabyte data sets. TheIBM Intelligent Miner includes a plurality of data mining techniques ortools, used to analyze large databases and provides visualization toolsused to view and interpret the different mining results. Examples ofother data mining techniques that may be employed are disclosed in U.S.Ser. No. 10/198,283 (Attorney Docket No. YOR920010625US1, filed on Jul.18, 2002, and entitled “Method and Apparatus for Providing Flexible andScalable Context Service.”

Referring now to FIG. 3, a flow diagram illustrates a user data entryvalidation methodology, according to an embodiment of the presentinvention. To further illustrate this reconciliation methodology 300, ahospital charging example is considered. An event of interest may be apatient's proximity to an MRI, x-ray, or primary physician.

Methodology 300 begins at step 310 wherein a specification of contextassociated with an event of interest is received. In one illustrativeembodiment, the specification is made by selecting at least one contextsource from available context sources (e.g., via menus or pull downs),specifying a range of values for the context source, and specifying therelationship between these sources. The ranges may be numerical (e.g.,temperature between 98.6 and 100 degrees), or may themselves be acollection of possible states (e.g., in one of several operating rooms).

The relationships may be logical (e.g., AND, OR, XOR) or may be composedof these logical relationships (e.g., Context A in range X AND Context Bin range Y, when Context C is “delayed during office hours”). Furtherthese relationships may be described by other terms (e.g., proximate,equal to Z). Note that context sources may be composed to provide morecomplex context (e.g., busy, rather than on-the-phone, or in-a- meeting,or in-the-operating room, or with-a-patient).

Other embodiments may include modifying a specification template tocreate a new specification, providing an indication of existingtemplates, accessing a template from a supplier of templates (e.g., froma Web source). In our example, the context sources are patient locationand physician location. We assume that MRI and x-ray locations are knownand constant. If they are mobile devices, then their location is also acontext source.

It is to be appreciated that the context being specified depends on thedata entry environment. However, some general examples of specifiedcontext may include a location, a time at location, a proximity to alocation, a proximity to a person, a proximity to a device, a proximityto a person satisfying a condition, a proximity to a location during aspecified time interval, an application invocation, a duration of anapplication invocation, a duration of an application focus on aparticular subject, an application invocation during a specified timeinterval, a user input, a duration of a user input session, a proximityto multiple persons and a location, data from an electronic calendar orscheduling program, a work assignment, and/or a workflow stage. It is tobe further appreciated that proximity may be determined in accordancewith an identification device (e.g., device ID, RFID) and may also bedetermined in accordance with an event type and/or a service identifier

Further, it is to be appreciated that events of interest may bespecified in a manner similar to or different from the manner in whichcontext is specified.

Methodology 300 continues in step 320, which operationalizes thespecification. In step 320, context is received and associated with theevents of interest. Context may be received from entities and devicessuch as, but not limited to: sensors (connected wirelessly or wired)that may be associated with a person or not associated with a person; acalendar program, location technology such as a global positioningsystem (GPS); a wireless access point; a RFID tag; an active badge;information technology (IT) components which may include themselvescalendars and reservation schedules. Context may be received inreal-time, near real-time, or batch mode (e.g., accumulate context dataand transfer accumulated context data at a later time).

Thus, it is to be appreciated that, in general, context may be receivedthrough a computer program, a file transfer, a batch mode, acommunications network (e.g., Ethernet 802.11, Bluetooth, cellular widearea network (WAN), Internet, etc.), a communications-enabled device(e.g., RFID tag), and a polling mechanism. Context may be received froma single source or from more than one source. Context may also bereceived from user entry and/or a video. Again, it is to be understoodthat the type of context and how it is received depends on the dataentry environment.

Further, in step 320, context received is then examined in conjunctionwith the specification of step 320. In our example, patient location isexamined in conjunction with known locations of MRI and x-rays, and withdynamic locations of physicians. When the context or composed contextmatches the specification, an indication of the match is provided. In anillustrative embodiment, the indication includes reference to time ofday, location, and/or other available data.

Further, in one illustrative embodiment, step 320 employs context logswhich contain historical context. For example, location context may becollected by a device such as a GPS-enabled PDA. The log of suchlocation context may be periodically transmitted to be used in step 320.Alternately, location context may be collected by a third party such asa cellular carrier and made available on a demand or on a periodicbasis. An example of one application employing such historical logs canbe found in validation of charges associated with client visits.Historical location context associated with an employee may be comparedto historical location context associated with a client, and charges forcustomer calls validated against determination of proximity of theemployee to the client.

In step 330, methodology 300 associates context received and examined instep 320 with user entries representing events of interest associatedwith the specification of 310. In our example, patient charges enteredby an administrator or hospital IT process or program are associatedwith the context stream of step 320. Charges may be associated with oneor more elements of context, composed context or analyzed context.Charges may be associated with none. Context may be associated with oneor more charges, or with none. Furthermore, the step of associatingcontext may be responsive to a time of day, a time of event of interest,a location of event of interest, a location of entity, a source ofcontext, and/or an entity associated with context.

In step 340, methodology 300 evaluates the user entries in light of thecontext. Confidence in user entries may be increased, decreased oruntouched by the information provided by the context. Such evaluationmay be done via algorithm, table or data look up, previousspecification, manually via user examination (e.g., show the user therelevant context streams and request confirmation). In our example, acharge for x-ray should be associated with a proximity of the patient tothe x-ray on that date. If no proximity had been recorded, doubt is caston the charge. If proximity was recorded and no charge was present,doubt is cast on the lack of charge. In one embodiment, user entriesmust be validated to be considered valid.

Thus, in general, evaluating user entries responsive to context mayinclude a determination of validity, a determination of a likelihood ofvalidity, a determination of a missing entry, and a determination of amissing element of an entry. Further, a defined workflow of correlatedevents may exist and the associated context uses the position in theworkflow for determination. For example, a workflow may be defined forfulfilling a service contract which includes authorization, purchase ofmaterials, and inspections. Purchase of materials, associated withlocation based context, which occurs at the wrong point of the workflow,may be precluded from association with the contract. In another example,medical procedures may be required to take place in a specific order.This workflow can be used in conjunction with context to identify missedcharges.

In step 350, methodology 300 provides an indication of the evaluationperformed in step 340. Such evaluation may be incremental, may occuronce upon completion, and may be done locally or remotely. Results ofthe evaluation may be provided to the user that made the entry or to athird party. The indication may be, by way of example, a data message,an audible message, a visual message, an error message, an error log, avalidation log, a confidence level. Methodology 300 ends at block 360.

Referring now to FIG. 4, a block diagram illustrates a computer systemin accordance with which one or more components/steps of a user dataentry system (e.g., components/steps described in the context of FIGS. 2and 3) may be implemented, according to an embodiment of the presentinvention. For example, the illustrative architecture of FIG. 4 may beused in implementing any and all of the components of data stores 230,240, 275 and 290, reconciliation engine 250, context service 270, andpattern miner 280 (as shown in FIG. 2). Also, the illustrativearchitecture of FIG. 4 may also be used in implementing any and all ofthe computing devices 205, 210, 215, 220, 245 and 260 (as shown in FIG.2).

Further, it is to be understood that the individual components/steps maybe implemented on one such computer system, or more preferably, on morethan one such computer system. In the case of an implementation on adistributed system, the individual computer systems and/or devices maybe connected via a suitable network (e.g., the Internet or World WideWeb). However, the system may be realized via private or local networks.The invention is not limited to any particular network.

As shown, the computer system 400 may be implemented in accordance witha processor 410, a memory 420, I/O devices 430, and a network interface440, coupled via a computer bus 450 or alternate connection arrangement.

It is to be appreciated that the term “processor” as used herein isintended to include any processing device, such as, for example, onethat includes a CPU (central processing unit) and/or other processingcircuitry. It is also to be understood that the term “processor” mayrefer to more than one processing device and that various elementsassociated with a processing device may be shared by other processingdevices.

The term “memory” as used herein is intended to include memoryassociated with a processor or CPU, such as, for example, RAM, ROM, afixed memory device (e.g., hard drive), a removable memory device (e.g.,diskette), flash memory, etc.

In addition, the phrase “input/output devices” or “I/O devices” as usedherein is intended to include, for example, one or more input devices(e.g., keyboard, mouse, etc.) for entering data to the processing unit,and/or one or more output devices (e.g., speaker, display, etc.) forpresenting results associated with the processing unit.

Still further, the phrase “network interface” as used herein is intendedto include, for example, one or more transceivers to permit the computersystem to communicate with another computer system via an appropriatecommunications protocol.

Accordingly, software components including instructions or code forperforming the methodologies described herein may be stored in one ormore of the associated memory devices (e.g., ROM, fixed or removablememory) and, when ready to be utilized, loaded in part or in whole(e.g., into RAM) and executed by a CPU.

It is to be further appreciated that the present invention also includestechniques for providing user data entry services.

By way of example, a service provider agrees (e.g., via a service levelagreement or some informal agreement or arrangement) with a servicecustomer or client to provide user data entry services. That is, by wayof one example only, the service provider may host the customer's website and associated applications (e.g., medical billing application,e-commerce application, etc.). Then, in accordance with terms of thecontract between the service provider and the service customer, theservice provider provides user data entry services which may include oneor more of the methodologies of the invention described herein. By wayof example, this may include automatically validating user data entriesbased on a context stream so as to provide one or more benefits to theservice customer. The service provider may also provide one or more ofthe context sources used in the validations. For example, the serviceprovider may provide location context, or electronic calendar services.

Although illustrative embodiments of the present invention have beendescribed herein with reference to the accompanying drawings, it is tobe understood that the invention is not limited to those preciseembodiments, and that various other changes and modifications may bemade by one skilled in the art without departing from the scope orspirit of the invention.

1. A method of processing one or more user entries associated with oneor more events of interest, comprising the steps of: obtaining contextassociated with the one or more events of interest; associating at leasta portion of the obtained context with one or more user entriesrepresenting events of interest; evaluating at least a portion of theone or more user entries responsive to at least a portion of thecontext; and providing an indication of the one or more events ofinterest responsive to the evaluation.
 2. The method of claim 1, furthercomprising the step of obtaining a specification of context associatedwith one or more events of interest.
 3. The method of claim 1, furthercomprising the step of specifying the one or more events of interest. 4.The method of claim 2, wherein the step of obtaining a specification ofcontext comprises obtaining at least one of a location, a time atlocation, a proximity to a location, a proximity to a person, aproximity to a device, a proximity to a person satisfying a condition, aproximity to a location during a specified time interval, an applicationinvocation, a duration of an application invocation, a duration of anapplication focus on a particular subject, an application invocationduring a specified time interval, a user input, a duration of a userinput session, a proximity to multiple persons and a location, acalendar, a work assignment, and a workflow stage.
 5. The method ofclaim 4, wherein obtaining a location comprises obtaining a physicallocation.
 6. The method of claim 5, further comprising the step ofmapping a physical location onto a logical location.
 7. The method ofclaim 4, wherein at least one of the proximities is determined inaccordance with an identification device.
 8. The method of claim 1,wherein context is obtained through at least one of a computer program,a file transfer, a batch mode, a communications network, acommunications-enabled device, and a polling mechanism.
 9. The method ofclaim 1, wherein context is obtained from one or more sources.
 10. Themethod of claim 1, wherein context is obtained from at least one of acalendar, a global positioning system, user entry, a video, a sensorassociated with a person, a sensor not associated with a person, and aproximity to a wireless access point.
 11. The method of claim 1, whereinthe step of associating context is responsive to at least one of a timeof day, a time of event of interest, a location of event of interest, alocation of entity, a source of context, and an entity associated withcontext.
 12. The method of claim 1, wherein evaluating the one or moreuser entries responsive to context comprises at least one of adetermination of validity, a determination of a likelihood of validity,a determination of a missing entry, and a determination of a missingelement of an entry.
 13. The method of claim 12, wherein a workflowexists and at least one of the determinations comprises determining atleast one workflow stage, the at least one workflow stage beingassociated with at least one context.
 14. The method of claim 1, whereinproviding an indication comprises at least one of providing a log, anerror message, a warning, a default entry, an amended entry, a newentry, a deleted entry, a workflow, an e-mail, and a notification. 15.The method of claim 1, wherein the evaluating step comprises the stepof, responsive to at least two sources of context, creating a composedsource of context.
 16. The method of claim 15, wherein the composedsource is created through a calculation.
 17. A method of validating oneor more expenses based on context data, comprising the steps of:obtaining context data in the form of a location history for at leastone user; responsive to user entry of one or more expenses incurred,determining a location associated with an expense; reconciling the userlocation history with the location associated with the expense;providing an indication of the reconciliation.
 18. The method of claim17, further comprising the step of obtaining location history for atleast one device.
 19. A method of validating a charge based on contextdata, comprising the steps of: obtaining context data in the form of acharge history for at least one client; and comparing one or morecurrent charges for the client to one or more previous charges for theclient.
 20. The method of claim 19, further comprising the step ofcomparing the one or more current charges for the client to previous,similar charges for other clients.
 21. A method of validating a chargebased on context data, comprising the steps of: obtaining context datain the form of a charge history for at least one employee; comparing acurrent charge for a client of the employee to one or more previouscharges originating from the employee for the client; and comparing thecurrent charge for the client of the employee to the previous chargesoriginating from the employee for all clients.
 22. Apparatus forprocessing one or more user entries associated with one or more eventsof interest, comprising: a memory; and at least one processor coupled tothe memory and operative to: (i) obtain context associated with the oneor more events of interest; (ii) associate at least a portion of theobtained context with one or more user entries representing events ofinterest; (iii) evaluate at least a portion of the one or more userentries responsive to at least a portion of the context; and (iv)provide an indication of the one or more events of interest responsiveto the evaluation.
 23. An article of manufacture processing one or moreuser entries associated with one or more events of interest, comprisinga machine readable medium containing one or more programs which whenexecuted implement the steps of: obtaining context associated with theone or more events of interest; associating at least a portion of theobtained context with one or more user entries representing events ofinterest; evaluating at least a portion of the one or more user entriesresponsive to at least a portion of the context; and providing anindication of the one or more events of interest responsive to theevaluation.
 24. A method of providing a service for validating one ormore user entries associated with one or more events of interest,comprising the steps of: a service provider providing a service to acustomer which comprises obtaining context associated with the one ormore events of interest, associating at least a portion of the obtainedcontext with one or more user entries representing events of interest,evaluating at least a portion of the one or more user entries responsiveto at least a portion of the context, and providing an indication of theone or more events of interest responsive to the evaluation.